1. SPP 單一職責原則:一個模組應只對唯一的一個角色負責
- 以角色為模組凝聚的核心
- 角色定義,因為相同時刻和原因,受到變動,視為同一同一個角色
- 在參與讀書會的過程中,我們有深入討論,怎麼樣該視為同一個角色,我自己的結論是,在設計的當下,或者可預期的未來,使用模組的人,都會因為在相同時刻和目的,使用者模組中的方法,那麼視為同一個角色,即使他們如書中說明,他們屬於不同部門,理由是沒有一步到位的設計,且永不變動的需求,所以時候到的時候,再來更改就好了,架構是隨著時間演化的
2. 凝聚是種力量,將程式碼綁定在一起,用來對角色負責
- 把相同相關的程式碼收攏再一起,或是把因為會有相同變動的程式碼歸納在一起,我一開始想到的是內聚性,書中提到這樣的好處是,避免為了類似的需求,碎片化的到處修改,此外也避免重複部署的成本,而我的理解是,至少對我最直接的幫助是,我知道要修改某需求,我只要到特定模組去就可以了,好變更,易維護
3.不遵守SRP 風險
- 意外重複 |多角色共用method ,造成互相牽制影響
- 書中提到的例子是HR系統,同時有三種角色在使用HR & 財務,他們共用計算加班薪資的方法,但萬一政府要修改加班認定的規則,那麼工程師修改加班薪資的方式,就會造兩個角色的衝突
- 合併修改|共同編輯一個類別,導致合併了修改
- 同上例子,簡單說就是兩個人改了同一份檔案,造成檔案合併修改,引發災難
解決辦法
-
將類別根據角色做拆分小類別
- 這是回歸到最根本問題,究竟你的類別使用者是誰?他們使用方法的時機為何
- Employ class → PayCalculator class & HourReporter class
-
Facade 模式
-
什麼是 Facade ?
- Facade 只負責實例化和委託具有函式的類別
- 用手洗衣服故事,來說明Facade模式
- 假設今天你要手洗衣服,你要做一系列動作,拿個桶子→放水→放洗衣精→浸泡衣服→用手搓揉→擰乾,想像每一個動作都需要調用一個類別的方法,光是手洗衣服這件事,就需要調用六個類別.
- 假設今天走到自動洗衣機,你只需要丟衣服,按下洗衣服,done! ,洗衣機自動幫你放水,浸泡,搓揉,脫水,你不需要知道洗衣機怎麼做到的,你只需要呼叫洗衣機類別,然後使用它的方法,這個方法就幫你把以上不同類別的方法調用完畢
參考
Facade 門面模式
直播研討會
-
Loading
找不到結果。
-